Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-098

Text File | 1995-12-31 | 42.4 KB | 1,094 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 19 May 95       Volume 3 : Issue 98

Today's Topics:

        Announce: Apple Guide Mailing List
        BOA Stacks between 2k and 24k
        Can large disk caches _really_ reduce performance _significantly?_
        Font Names: GX versus QD
        How do I determine whether 'x' is an OSTrap or a ToolTrap?
        Macintosh Port of STL available
        QuickDraw GX programming on the WWWeb
        [Ann] TCP++.Lib 1.0 released to macgifts
        help: making PICT header for JFIF format file
        lists in dialogs?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Quinn "The Eskimo!")
Subject: Announce: Apple Guide Mailing List
Date: Fri, 28 Apr 1995 21:06:07 +0800
Organization: Department of Computer Science, University of Western Australia

[I apologise if you see this twice but I have a sneaking suspicion I stuffed
 up the first posting.]

Greetings

It is my pleasure to announce the availablity of a mailing list for the
discussion of issues related to creating Apple Guide guide files.  At the
moment, I'm the only person on the list.  I asked "If I build it, will you
come?"  I hope so (-:  Thanks to Peter N Lewis for hosting the list.

How To Subscribe
- --------------
You can subscribe to the list by sending mail to...

  [e-mail]

... with the following in the body of the message...

  subscribe apple-guide Your Real Name

The message's subject is ignored.

How To Post
- ---------
You must be subscribed to send messages to the list.  Once you get your
subscription confirmation, you can send messages to the list by sending
them to...

  [e-mail]

Messages are not echoed back to you.

Share and Enjoy.
--
Quinn "The Eskimo!"    Pez:      "What's with all the happy sounds?"
                       Giggywig: "They're giddy with fear."

---------------------------

>From [e-mail] (Des Courtney)
Subject: BOA Stacks between 2k and 24k
Date: Thu, 27 Apr 1995 14:18:49 -0500
Organization: Flair Diversions

I'm interested in creating a BOA that runs in a tight memory space, but
  I'm concerned that the default 2k is not enough for my needs.  However,
  I've read that trying to adjust the stack smaller than 24k automatically
  makes the stack 24k.  I'm using Think Pascal 4.0.2, so if there are
  additional problems with BOA design under this environment, let me know.

Des Courtney

--
Flair Diversions is... Des Courtney, writer of cool Mac software
         Outpost Nexus, Ambiance, Icons for MICN, etc.
  mailto:[e-mail]  http://nether.net/~dcourtn/www
               Obligatory ASCII graphic --> (-;

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 27 Apr 1995 23:51:13 -0500
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Des Courtney) wrote:

< I'm interested in creating a BOA that runs in a tight memory space, but
<   I'm concerned that the default 2k is not enough for my needs.  However,
<   I've read that trying to adjust the stack smaller than 24k automatically
<   makes the stack 24k.  I'm using Think Pascal 4.0.2, so if there are
<   additional problems with BOA design under this environment, let me know.
<
< Des Courtney
<
< --
< Flair Diversions is... Des Courtney, writer of cool Mac software
<          Outpost Nexus, Ambiance, Icons for MICN, etc.
<   mailto:[e-mail]  http://nether.net/~dcourtn/www
<                Obligatory ASCII graphic --> (-;

It is possible to set the stack to any arbitrary size.  Here is some C
code that I've used for that purpose, where stackSize is the size of stack
you want in bytes:

      // It's not possible to set the stack to be smaller than
      // DfltStack.  So we adjust it first, set the
      // stacksize and then restore it.
      long  saveDefaultStack = LMGetMinStack();
      LMSetMinStack( stackSize );

      // Increase the stack size by lowering the heap limit.
      SetApplLimit( (Ptr) ( (unsigned long) GetApplLimit() - stackSize ) );
      LMSetMinStack( saveDefaultStack );

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 04 May 1995 13:09:39 +0800
Organization: Curtin University

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

>It is possible to set the stack to any arbitrary size.  Here is some C
>code that I've used for that purpose, where stackSize is the size of stack
>you want in bytes:

While this is true, I strongly recomend you don't do this.  I've done this
myself, and after a while I got sick of the complaints that my app was
crashing because the user had installed some new system extension that
wanted some more stack space.  Unfortunately, under System 7, there is no
way to keep other people off your stack or out of your heap, and any
number of inits will invalidate all your assumptions about stack space.
   Peter.
--
I will be in the USA during May so any Email will probably not be
dealt with until the start of June unless it's urgent.

+++++++++++++++++++++++++++

>From [e-mail] (Des Courtney)
Date: Thu, 04 May 1995 11:33:09 -0500
Organization: Flair Diversions

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

) While this is true, I strongly recomend you don't do this.  I've done this
) myself, and after a while I got sick of the complaints that my app was
) crashing because the user had installed some new system extension that
) wanted some more stack space.  Unfortunately, under System 7, there is no
) way to keep other people off your stack or out of your heap, and any
) number of inits will invalidate all your assumptions about stack space.
)    Peter.

Okay, then what is the *effective* minimum size a BOA's stack and heap can
  be?  Right now, my foreground version of Ambiance uses 24k stack and
  24k heap.  I want to know if I can save any memory by going back-only.
  (All interface will be done via a pref file and a separate config
  application or control panel.)

E-mail me a response; I will be off the 'Net for the summer this weekend.

Des Courtney

--
Flair Diversions is... Des Courtney, writer of cool Mac software
         Outpost Nexus, Ambiance, Icons for MICN, etc.
  mailto:[e-mail]  http://nether.net/~dcourtn/www
               Obligatory ASCII graphic --> (-;

---------------------------

>From [e-mail] (Daniel P. B. Smith)
Subject: Can large disk caches _really_ reduce performance _significantly?_
Date: Sat, 15 Apr 1995 23:17:25 GMT
Organization: The World Public Access UNIX, Brookline, MA

Obviously, setting the disk cache too large may not be the optimum thing
to do because a) the performance improvement may hit a law of diminishing
returns; b) you have to take the RAM _away_ from something else, and maybe
the something else would benefit performance more; c) in _theory_, there
could be a very _slight_ performance hit from having to "search a large
cache."  Setting aside a) and b), is there any truth to c?  It seems to
me that even if you have, say, a 2 meg cache, storing 2K blocks,
you'd have a sector table with 1K entries, and "searching" the table--
even by with a linear search--would take, jeez, I dunno, maybe 50
microseconds?  Adding 50 microseconds per sector to a system that was
reading at 2 meg/sec = 1000 blocks/second = 1000 microseconds per clock
would only be a 5% speed reduction.

There is a sort of "urban legend" in my company that says "the Mac disk
cache is terrible and will hurt performance terribly if you make it bigger
than 128K."  Someone produced a technical note from AppleLink in which
the querent wanted to know why an Excel file that saved in 40 seconds on
his Mac IIfx was taking over 2 minutes on his Mac Quadra (800, I think,
running 7.1).  The respondent, from Apple, asserted that it was because
his disk cache, at 512K, was too big, and that was causing it.

I've done some experiment of my own (all on PowerMacs with System 7.5) that
don't seem to bear this out, at all.  I'm not even sure I see _any_ effect
on raw read/write speeds of sequential files, whereas there are certain
situations where the disk thrashes a bit with a small cache and, as
you expect, quiets down and speeds up noticably with a big one.

How about it--has anyone seen _serious_ performance penalties from using
too large a disk cache (that were NOT attributable to starving an app
for RAM)?  Suppose you had a Mac with a 128K cache, and a 10 meg RAM disk,
and 64 meg of RAM total.  Does anybody believe that changing it to a 1 meg
cache and a 9 meg RAM disk would really reduce disk performance
significantly, and, if so, why?  (Again, I don't mean 5% slower, I mean
something taking 2 minutes instead of 40 seconds.)

The real reason I want to know is that, for other reasons, I want to
recommend using a largish cache size (512K to 1 meg) for our customers
(who typically use Macs with 64K to 96K of RAM in them).  I've been
testing with a PowerMac 8100/80 running 7.5 and I'm convinced this
recommendation _is_ OK on _this_ system.  _If_ the truth is that it
is OK on this system, but for some reason really _is_ bad (I mean
2 minutes versus 40 seconds bad) on some other system, I'd like to know
about it.

Anyone have any real information on how the cache works and whether
there's anything unexpected about its caching algorithm?

--
Daniel P. B. Smith
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Joseph "Moof-in'" Hall)
Date: Sun, 16 Apr 95 17:58:08 MST
Organization: 5 Sigma Software


In article <[e-mail]> (comp.sys.mac.programmer.misc), [e-mail] (Daniel P. B. Smith) writes:
) [...] The respondent, from Apple, asserted that it was because
) his disk cache, at 512K, was too big, and that was causing it.
)
) I've done some experiment of my own (all on PowerMacs with System 7.5) that
) don't seem to bear this out, at all.

That's because the 7.5 cache actually works well.

=============== O Fortuna, velut Luna, statu variabilis ===============
uunet!joebloe!joseph   [phone] day   [e-mail]
1400 N Alma School                #163               Chandler, AZ 85224
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
           Be hip!  Support comp.sys.mac.programmer.moof!

+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: 18 Apr 1995 10:45:17 GMT
Organization: The University of Western Australia

Daniel P. B. Smith ([e-mail]) wrote:
[snip]

: The real reason I want to know is that, for other reasons, I want to
: recommend using a largish cache size (512K to 1 meg) for our customers
: (who typically use Macs with 64K to 96K of RAM in them).  I've been
                               ^^^    ^^^
: testing with a PowerMac 8100/80 running 7.5 and I'm convinced this
: recommendation _is_ OK on _this_ system.  _If_ the truth is that it
: is OK on this system, but for some reason really _is_ bad (I mean
: 2 minutes versus 40 seconds bad) on some other system, I'd like to know
: about it.
[snip]
: --
: Daniel P. B. Smith
: [e-mail]

Hehe, personally I wouldn't recommend a 512K disk cache on a machine with
64K of RAM, but I don't know, maybe its just me.... ;-)

Scott Kevill.
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 19 Apr 1995 03:07:14 -0400
Organization: America Online, Inc. (1-800-827-6364)

>Obviously, setting the disk cache too large may not be the optimum thing
>to do because a) the performance improvement may hit a law of diminishing
>returns; b) you have to take the RAM _away_ from something else, and
maybe
>the something else would benefit performance more; c) in _theory_, there
>could be a very _slight_ performance hit from having to "search a large
>cache."  Setting aside a) and b), is there any truth to c?  It seems to
>me that even if you have, say, a 2 meg cache, storing 2K blocks,
>you'd have a sector table with 1K entries, and "searching" the table--
>even by with a linear search--would take, jeez, I dunno, maybe 50
>microseconds?  Adding 50 microseconds per sector to a system that was
>reading at 2 meg/sec = 1000 blocks/second = 1000 microseconds per clock
>would only be a 5% speed reduction.
>
>There is a sort of "urban legend" in my company that says "the Mac disk
>cache is terrible and will hurt performance terribly if you make it
bigger
>than 128K."  Someone produced a technical note from AppleLink in which
>the querent wanted to know why an Excel file that saved in 40 seconds on
>his Mac IIfx was taking over 2 minutes on his Mac Quadra (800, I think,
>running 7.1).  The respondent, from Apple, asserted that it was because
>his disk cache, at 512K, was too big, and that was causing it.
>
>I've done some experiment of my own (all on PowerMacs with System 7.5)
that
>don't seem to bear this out, at all.  I'm not even sure I see _any_
effect
>on raw read/write speeds of sequential files, whereas there are certain
>situations where the disk thrashes a bit with a small cache and, as
>you expect, quiets down and speeds up noticably with a big one.
>
>How about it--has anyone seen _serious_ performance penalties from using
>too large a disk cache (that were NOT attributable to starving an app
>for RAM)?  Suppose you had a Mac with a 128K cache, and a 10 meg RAM
disk,
>and 64 meg of RAM total.  Does anybody believe that changing it to a 1
meg
>cache and a 9 meg RAM disk would really reduce disk performance
>significantly, and, if so, why?  (Again, I don't mean 5% slower, I mean
>something taking 2 minutes instead of 40 seconds.)
>
>The real reason I want to know is that, for other reasons, I want to
>recommend using a largish cache size (512K to 1 meg) for our customers
>(who typically use Macs with 64K to 96K of RAM in them).  I've been
>testing with a PowerMac 8100/80 running 7.5 and I'm convinced this
>recommendation _is_ OK on _this_ system.  _If_ the truth is that it
>is OK on this system, but for some reason really _is_ bad (I mean
>2 minutes versus 40 seconds bad) on some other system, I'd like to know
>about it.
>
>Anyone have any real information on how the cache works and whether
>there's anything unexpected about its caching algorithm?

Ah... where do I start. There have been three major releases of the File
Manager's disk cache since HFS was released: the pre-System 7 cache, the
System 7.0 through 7.1.2 cache, and the System 7.5 cache.

I haven't spent a lot of time looking at what exactly changed between
System 6 and System 7.0, but the 2 major changes in performance were:

1) Cached multiple block reads are made directly into the user's buffer
and then moved into the cache. The pre-7.0 cache used to read single
blocks into the cache from disk (really slow) and then copy them into the
user's buffer.

2) When a file is closed, cache blocks associated with that file are moved
into a "free queue". If the file is reopened and the same blocks are read
again, they are retrieved from the free queue (if they haven't been
reused) which is searched using a hash mechanism.

System 7.5 changed several other things which cause performance problems.
Again, I haven't looked at every little change, but the major changes
were:

1) RAM disks aren't cached. A disk is determined to be a RAM disk if it
returns $10 in the LS-byte of the information returned by a csCode 23
(Return Drive Info) Control call to the disk driver (see the Tech Note
"What Your Sony Drives For You for a description of the Return Drive Info
Control call). (And yes, I know that's not documented *yet*). RAM disk
volumes are marked by the HFS file system with a bit in vcbAtrb (I can't
remember which - it's easy to see).

2) All BlockMoves were changed to BlockMoveData.

3) When dirty cache blocks are flushed, the dirty cache blocks that are
contiguous on disk are moved to a temporary buffer and then written. This
results in fewer and larger write operations (which is much faster).

4) Cached multiple block reads used to flush all of the file's dirty
blocks to the disk before reading (to make sure no stale data would be
read from disk). Now, the read into the buffer is made first and then the
cache is searched for dirty blocks associated with the file. Dirty blocks
are then copied over the data read with BlockMoveData. This is a big speed
increase since only one I/O operation (the read) is made.

So, that should be enough to help your figure out why the File Manager
cache sucked in some cases before System 7.5.

If everyone would pay a little more attention to what they cached or
didn't cache, and would pay attention to how they performed their I/O
operations, things could be even faster on the Macintosh. See the newly
revised Technical Note "FL 16 - File Manager Performance and Caching"
(just uploaded to DTS's Web page) for more information.

- Jim Luther

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Ice x2136)
Date: 19 Apr 1995 12:46:25 GMT
Organization: Allen-Bradley Co.

Joseph "Moof-in'" Hall ([e-mail]) wrote:

:>In article <[e-mail]> (comp.sys.mac.programmer.misc), [e-mail] (Daniel P. B. Smith) writes:
:>) [...] The respondent, from Apple, asserted that it was because
:>) his disk cache, at 512K, was too big, and that was causing it.
:>)
:>) I've done some experiment of my own (all on PowerMacs with System 7.5) that
:>) don't seem to bear this out, at all.

My understanding is that, *before sys 7.5*, the caching algorithm used for
cacheing was poor and inefficient.  Large cache sizes meant the cpu spent more
time fiddling with the 1.5M cache you've created rather than just fetching
from disk.

*I believe* that Sys7.5 has improved algorithms that help alleviate this
problem, but again...there's a point of diminishing returns on cache size.
You'll just have to experiment to see what works best for a particular
machine/drive combo.

Chris
--
                                  --------
  +------------------------------| _   /| |------------------------------+
  | Chris Ice, Software Engineer | \`o_O' | Allen-Bradley Company        |
  | E-mail: [e-mail]     |   ( )  | 1201 S. Second St.           |
  | Voice:  414.382.2136         |    U   | Milwaukee, WI 53204 USA      |
  +------------------------------|  Ack!  |------------------------------+
      My opinions do not reflect  --------  the views of my employer.

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Tue, 25 Apr 1995 14:25:43 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Daniel P.
B. Smith) wrote:

> Anyone have any real information on how the cache works and whether
> there's anything unexpected about its caching algorithm?

Others have answered this but I can add a few things --

* Pre-7.5 the disk cache would flush one block at a time. This made
flushing very, very slow. The disk cache was rewritten from scratch for
7.5 and it shows. Large caches now work very well.

* There are special flags your code can use to indicate to the File
Manager that data it's writing should not be stored in the cache. This is
good to use for file copies or other times when you know what you're
writing will not necessarily be read again soon.

* There's a brand new Tech Note (available by WWW from www.info.apple.com)
that describes various techniques to speed up file I/O, including how to
use the aforementioned caching bits.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

---------------------------

>From [e-mail] (Alan Jay Swire)
Subject: Font Names: GX versus QD
Date: Thu, 27 Apr 1995 13:20:30 -0400
Organization: Eastman Kodak

How does one translate between the font names that one can obtain through
Quickdraw, and font names in QuickdrawGX? All our fonts have been
translated by the Type 1 Enabler into GX format, but using QD names for
the font will not find the GX names for the font. An example, "ACaslon
Italic" is the name for one of our fonts obtained through QD, but the GX
name for the font obtained through GXFindFontName() is "Adobe Caslon
Italic". I have been searching through the GX manuals for a conversion of
the Font Number obtained through GetFNum() into something useful for GX,
but I have been unsuccessful. Any ideas?

Alan

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 27 Apr 1995 15:33:40 -0700
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]>,
Alan Jay Swire <[e-mail]> wrote:
>How does one translate between the font names that one can obtain through
>Quickdraw, and font names in QuickdrawGX? All our fonts have been
>translated by the Type 1 Enabler into GX format, but using QD names for
>the font will not find the GX names for the font. An example, "ACaslon
>Italic" is the name for one of our fonts obtained through QD, but the GX
>name for the font obtained through GXFindFontName() is "Adobe Caslon
>Italic". I have been searching through the GX manuals for a conversion of
>the Font Number obtained through GetFNum() into something useful for GX,
>but I have been unsuccessful. Any ideas?
>
>Alan

Quickdraw font names come from the resources, while GX font names come
from the 'name' table in the 'sfnt'. To go from GX's name space to
Quickdraw's, you can use the FontToQD function (in the font menu library
that comes with GX on the developer CDs) to convert a gxFont into a
FOND ID. Once you have that ID, GetFName or equivalent can get you the
Quickdraw name. To go the other direction, you can use the GXNewFont
call with the resourceFontStorage type to make a gxFont from a given
sfnt in a FOND, and then once you have the gxFont you can call
GXFindFontName to find the appropriate name.

Dave Opstad
GX Line Layout Weenie


---------------------------

>From [e-mail] (Reinder Verlinde)
Subject: How do I determine whether 'x' is an OSTrap or a ToolTrap?
Date: Thu, 27 Apr 1995 13:04:33 GMT
Organization: Rijksuniversiteit Utrecht


While converting some old code to the universal headers, with

   #define OLDROUTINENAMES 0

I encountered code which patches ExitToShell (to ensure that some
cleanup code is executed). This brings me to the question: what
does one pass to NGetTrapAddress and NSetTrapAddress??
The prototypes state:

extern pascal UniversalProcPtr NGetTrapAddress(
                                    short trapNum, TrapType tTyp);

extern pascal void NSetTrapAddress(
            UniversalProcPtr trapAddr, short trapNum, TrapType tTyp);

For the trapNum parameter, I have seen source which uses 0xA9F4, code
which uses 0x01A4, and I think that I have even seen code which uses
0x00A4. The code in question used 0xA9F4, and I think that that is
what I have used whenever I patched traps, so I stuck with that.

For tTyp, the big question is: do I pass OSTrap or ToolTrap?

According to both the phonebook (IM I, II, and III in a single binder)
and IM IV we have:

  "Bit 11 of the trap word determines how the remainder of the word will
   be interpreted; usually it's 0 for Operating System calls and 1 for
   Toolbox calls, though there are certain exceptions"

So, unless ExitToShell is an exception, it is a Toolbox Trap. However, my
gut feeling is that it is an Operating System Trap, and the code seems
to work when I use OSTrap.

Problem is, I can't find the list of exceptions. Reading on about the question:

    "How do you determine whether a trap is a ToolTrap or an OSTrap???"

I began to wonder why GetTrapAddress was ever replaced by NGetTrapAddress.
If everybody simply passes the entire trap word (0xA9F4 for ExitToShell)
the TrapType parameter is not needed. The only reason for the NGet/NSet
pair I can see is that older programs may have passed less information
(0x1A4 for ExitToShell)

The original question remains a mystery to me, however. Things I can
come up with are:

  - don't bother, just pass the entire trap word (e.g. 0xA9F4),
    GetTrapAddress and SetTrapAddress are smart enough to figure out what
    you mean in that case. The whole distinction between OS and toolbox
    traps is just a formality.

  - just use the rule 'bit 11 set <=> toolbox trap'

  - Toolbox traps use Pascal calling conventions, OS Traps use registers.
    This would not help for ExitToShell, since its prototype is

          pascal void ExitToShell( void);

  - OSTraps are discussed in OS Chapters, Tool Traps in Toolbox chapters
    of IM (of course that begs the question: what is a OS Chapter, what a
    Toolbox chapter)

If anybody can shed light on this I would be grateful.

Reinder Verlinde

PS: Excuse me if this post turns up twice. I have reason to believe that
    my first posting was not received by my newshost, but I may be wrong.

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: Thu, 27 Apr 1995 13:11:19 -0500
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Reinder Verlinde) wrote:

< While converting some old code to the universal headers, with
<
<    #define OLDROUTINENAMES 0
<
< I encountered code which patches ExitToShell (to ensure that some
< cleanup code is executed). This brings me to the question: what
< does one pass to NGetTrapAddress and NSetTrapAddress??
< The prototypes state:
<
< extern pascal UniversalProcPtr NGetTrapAddress(
<                                     short trapNum, TrapType tTyp);
<
< extern pascal void NSetTrapAddress(
<             UniversalProcPtr trapAddr, short trapNum, TrapType tTyp);

I never use NGet/NSet.  I always use GetTool/SetTool/GetOS/SetOS.  If you
disassemble code written using NGet you'll see that it has more overhead.
I always pass the defines for a particular trap that are found in
Traps.h.  Something like this:

   mExitToShellUPP = ::GetToolTrapAddress( _ExitToShell );
   mExitToShellPatchUPP =
      NewRoutineDescriptor( (ProcPtr) ExitToShellPatch, kPascalStackBased,
GetCurrentISA() );
   ::SetToolTrapAddress( mExitToShellPatchUPP, _ExitToShell );

<
< For the trapNum parameter, I have seen source which uses 0xA9F4, code
< which uses 0x01A4, and I think that I have even seen code which uses
< 0x00A4. The code in question used 0xA9F4, and I think that that is
< what I have used whenever I patched traps, so I stuck with that.
<
< For tTyp, the big question is: do I pass OSTrap or ToolTrap?
<
< According to both the phonebook (IM I, II, and III in a single binder)
< and IM IV we have:
<
<   "Bit 11 of the trap word determines how the remainder of the word will
<    be interpreted; usually it's 0 for Operating System calls and 1 for
<    Toolbox calls, though there are certain exceptions"
<
< So, unless ExitToShell is an exception, it is a Toolbox Trap. However, my
< gut feeling is that it is an Operating System Trap, and the code seems
< to work when I use OSTrap.

Yes it's a tooltrap.

<
< Problem is, I can't find the list of exceptions. Reading on about the
question:
<
<     "How do you determine whether a trap is a ToolTrap or an OSTrap???"
<
< I began to wonder why GetTrapAddress was ever replaced by NGetTrapAddress.
< If everybody simply passes the entire trap word (0xA9F4 for ExitToShell)
< the TrapType parameter is not needed. The only reason for the NGet/NSet
< pair I can see is that older programs may have passed less information
< (0x1A4 for ExitToShell)
<
< The original question remains a mystery to me, however. Things I can
< come up with are:
<
<   - don't bother, just pass the entire trap word (e.g. 0xA9F4),
<     GetTrapAddress and SetTrapAddress are smart enough to figure out what
<     you mean in that case. The whole distinction between OS and toolbox
<     traps is just a formality.

Not true.  There are really two trap tables and if you pass the wrong
traptype your patch won't get called.

<
<   - just use the rule 'bit 11 set <=> toolbox trap'

This works.

<
<   - Toolbox traps use Pascal calling conventions, OS Traps use registers.
<     This would not help for ExitToShell, since its prototype is
<
<           pascal void ExitToShell( void);

True.  Traps from Memory Manager, File Manager, and Device Manager for
example, use register-based calling conventions and are OSTraps (mostly).

<
<   - OSTraps are discussed in OS Chapters, Tool Traps in Toolbox chapters
<     of IM (of course that begs the question: what is a OS Chapter, what a
<     Toolbox chapter)
<
< If anybody can shed light on this I would be grateful.

I sometimes, um, well, do this by trial and error.  If you pass the wrong
traptype then your patch isn't called.  If the patch isn't called then I
change the traptype.  Simple as that.

<
< Reinder Verlinde
<
< PS: Excuse me if this post turns up twice. I have reason to believe that
<     my first posting was not received by my newshost, but I may be wrong.

Good luck,

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 28 Apr 1995 16:27:37 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Reinder Verlinde <[e-mail]> wrote:

>    "How do you determine whether a trap is a ToolTrap or an OSTrap???"
>
>  - just use the rule 'bit 11 set <=> toolbox trap'

As far as I know, this rule is correct. Of course, as you noted, that leads
us to ask why the System doesn't determine this itself instead of asking us
to call SetToolTrapAddress or SetOSTrapAddress accordingly. Maybe a leftover
from the old days?

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

---------------------------

>From [e-mail] (Tom Emerson)
Subject: Macintosh Port of STL available
Date: Fri, 05 May 1995 10:51:49 -0400
Organization: Symantec Development Tools Group

The Symantec Macintosh Development Tools Group would like to announce the
availability of a Macintosh ported version of the Standard Template
Library (STL) which includes a demonstration created by ObjectSpace and
available on the HP ftp server.

This version will work properly with our 8.0.1 compilers which were
released yesterday and are available on the Symantec DTS ftp server,

<ftp://devtools.symantec.com/macintosh/updaters/devtools/sym.cpp-va-tcl.updates/sym-spm-801-update.hqx>

We will continue maintain the STL archive.

About the STL and demo
- --------------------
This archive contains an update to the Standard Template Library and A new
demo of the STL that was posted to the HP ftp site. It requires that your
compilers be updated to 8.0.1 before it can be used. If you have not
already obtained this updater from our online services, please do so.

NOTE: The STL and examples provided will not work correctly without the
8.0.1 compiler update.

Getting the STL and demo
- ----------------------
The contents of the STL and demo can be found at the following URL:

<ftp://ftp.bedford.symantec.com/pub/stl/STL_and_demo.hqx>

Questions regarding our Development Tools can be sent to

<mailto:[e-mail]>

bug reports should be sent to

<mailto:[e-mail]>

If you want to be notified when a release is made from the Development
Tools Group, send a message to

<mailto:[e-mail]>

With the subject line

sub macdtg-announce <your real name>

- -
Tom Emerson                                              Software Engineer
Development Tools Group                               Symantec Corporation
                          [e-mail]
                "Reptiles Unite! Down with the Mammalarchy!"

---------------------------

>From [e-mail] (Lawrence D9Oliveiro)
Subject: QuickDraw GX programming on the WWWeb
Date: Tue, 02 May 1995 16:49:19 +1200
Organization: University of Waikato

I've put together some World-Wide Web pages that introduce some of the
aspects of programming for QuickDraw GX. You'll find them at

    http://www2.waikato.ac.nz/ldo/gx/intro.html

Have fun.

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

---------------------------

>From [e-mail] (Josh Adams)
Subject: [Ann] TCP++.Lib 1.0 released to macgifts
Date: Fri, 28 Apr 1995 07:10:40 -0400
Organization: University of Maryland College Park

I just submitted my TCP++.Lib 1.0 to [e-mail].

What, you may be asking is the TCP++.lib?

Well, it is a library for CodeWarrior that greatly eases the coding of TCP
applications. I used code that I found included in the source for inetd.
It was apparently written by Apple in MPW.

I updated all the code so that it would compile under CodeWarrior. The
source uses some C++.

I include all the source and the CW project I used. There is also an
explanatory README file.

I don't know when it will be available, but I will post again when it is.

I would appreciate people trying it out and telling me what they think. I
haven't used it incredibly much myself. In fact, I don't think that it
easily creates a Passive TCP stream...

Anyway, good luck...

Josh

--
Josh Adams                       |  Will she trick or treat,
Mail: [e-mail]         |  I bet she will.
Talk: [e-mail]      |    - Type O Negative

---------------------------

>From [e-mail] (Ken Cunningham)
Subject: help: making PICT header for JFIF format file
Date: Sun, 30 Apr 1995 09:07:15 -0800
Organization: MD, FRCPC

Having looked through Apple's Quicktime documentation, and opened a few
JPEG-compressed PICT and JFIF files, I understand that the two file
formats are virtually identical, except for the 512byte header of zero's
and the about 240byte Quicktime header that is attatched to the start of
the JFIF file to make it a PICT file.

I assume the resource would be similar, but without the header of zero's,
as usual.

Has anyone put some code together that will look at the JFIF file and
build the correct Quicktime-PICT header?

If not that, could someone help me with the JFIF header?

Thanks, all...

+++++++++++++++++++++++++++

>From Kent Sandvik <[e-mail]>
Date: 30 Apr 1995 22:09:03 GMT
Organization: Apple Computer, Inc. Developer Tech. Support

In article <[e-mail]> Ken Cunningham,
[e-mail] writes:
>>Having looked through Apple's Quicktime documentation, and opened a few
>JPEG-compressed PICT and JFIF files, I understand that the two file
>formats are virtually identical, except for the 512byte header of zero's
>and the about 240byte Quicktime header that is attatched to the start of
>the JFIF file to make it a PICT file.
>
>I assume the resource would be similar, but without the header of zero's,
>as usual.
>
>Has anyone put some code together that will look at the JFIF file and
>build the correct Quicktime-PICT header?
>
>If not that, could someone help me with the JFIF header?

Ho! This should be a FAQ. Actually it's a Q&A, part of the new Q&A drive
we are doing, and will be announced at the WWDC.

Anyway, JFIF is the container format for distributing JPEG movies from
system to system without worrying about byte ordering, data construct
sizes and so on.

A very common question is now to scan and build an image description from
a JFIF file, and the answer is in the ScanJFIF function that is part of
the Movie Data Exchange QuickTime samples. And those samples should be
available on most online services where we have uploaded sample code, as
well as on the QT 2.0 SDK CD that most QT-professionals should own by now.

Cheers, Kent

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Mon, 1 May 1995 04:40:47 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3o11pv$[e-mail]> Kent Sandvik <[e-mail]> writes:
>A very common question is now to scan and build an image description from
>a JFIF file, and the answer is in the ScanJFIF function that is part of
>the Movie Data Exchange QuickTime samples.

Yes, but!

At least the version of ScanJFIF on the most recent Developer's CD-ROM
is old, and errors out when handed a JFIF file with version 1.02 or greater.
(It handles only versions 1.00 and 1.02.)

Where is the JFIF header documented?

What is the current version?
--
- ------- <mail-to:[e-mail]> ----------
Ahh! The thorazine is wearing off and the odinazine is coming on...

+++++++++++++++++++++++++++

>From [e-mail] (Tom Lane)
Date: Mon, 1 May 1995 14:10:01 GMT
Organization: Netcom Online Communications Services

[e-mail] (David Phillip Oster) writes:
> At least the version of ScanJFIF on the most recent Developer's CD-ROM
> is old, and errors out when handed a JFIF file with version 1.02 or greater.
> (It handles only versions 1.00 and 1.02.)

I guess you meant it handles only 1.0 and 1.01?  They did the wrong
thing here, because a new minor version is specified to be upward
compatible.  Barfing on an unknown minor number is wrong.

> Where is the JFIF header documented?

ftp.uu.net:/graphics/jpeg/jfif.ps.gz (there's also a plain text version).

> What is the current version?

1.02 is still the current version and is likely to be the last version
ever, because the JPEG committee is more interested in their new "SPIFF"
format.  (SPIFF is compatible with JFIF as long as you don't expect the
JFIF APP0 marker to be there.)

Unfortunately, some twit got the high and low version bytes backwards in
the latest release of HiJaak Pro, with the result that files claiming to
be JFIF version 2.01 are starting to appear.  Since a major version
upgrade is specified to mean an incompatible change, it is proper to
reject these files; but depending on how anal-retentive you want to be,
you might prefer to just ignore the JFIF version number entirely.

                        regards, tom lane
                        organizer, Independent JPEG Group

---------------------------

>From Said Kobeissi <[e-mail]>
Subject: lists in dialogs?
Date: 1 May 1995 19:20:40 GMT
Organization: TOGETHER INTERNET SERVICES

Hi all,

  I am sure this is a common question, so feel free to point me towards
some source code or sample materials (in C preferably). How does one
display a list in a dialog?

Thank you,

  Said

[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (MuffinHead)
Date: 2 May 1995 07:16:17 GMT
Organization: Armpit Studios VII

In article <3o3ca8$[e-mail]>, Said Kobeissi
<[e-mail]> wrote:

>  I am sure this is a common question, so feel free to point me towards
>some source code or sample materials (in C preferably). How does one
>display a list in a dialog?

   Create the list with LNew, add all the stuff to it, create a userItem
in your dialog with the rect of the list, create a userItemProc for it
that calls LUpdate so it will draw when you receive update events, and
handle clicks on the list in your filterProc. Also, stick the ListHandle
in the dialog's refCon so you can get to it from within the userItemProc
and other places without having to make it a global. Here's a *very*
primal example:

{
   ListHandle list;
   Rect box;
   short i;
   Handle h;
   UserItemUPP uiUPP;

   GetDialogItem(d, yourUserItemNumber, &i, &h, &box);
   uiUPP = NewUserItemProc(listDrawingUserItem);
   SetDialogItem(d, yourUserItemNumber, i, (Handle)uiUPP, &box);
   list = LNew(&box, ...);
   // Add your columns and rows and the cell data here.

   do {
      ModalDialog(blah...);
   } while(whee...);

   DisposeRoutineDescriptor(uiUPP);
   etc...
}

pascal void listDrawingUserItem(DialogPtr d, short n)
{
   ListHandle list;

   list = (ListHandle)GetWRefCon(d);
   LUpdate(d->visRgn, list);
   // I've found that I need to also draw the list's frame sometimes.
   // It doesn't seem to update after a balloon erases it:
   FrameRect(&(**list).rView);
}

   Just play around with that. You'll easily figure out the rest.

Muff                                               Armpit Studios VII
Drummer, Mac geek                                       Iowa City, IA
_____________________________________________________________________
Boy, giraffes are selfish.
  --Deputy Bernard [P.|Milton|Oliver] Fife

---------------------------

End of C.S.M.P. Digest
**********************